Over the years the term “security” as applied to server technology, and particularly to e-commerce servers, has expanded to cover several aspects of a secure environment. The original definition of the term has always envisaged a mechanism for validating a particular user's (or client's) identity, and preventing that user from retrieving, viewing, or otherwise accessing, information on the server which they are not allowed to access.
FIG. 1 shows a typical example of a security mechanism commonly used today. Clients 102, 104 access a secured resource such as an application server 106 via a number of protocols; including for example http (hypertext transfer protocol) 110 and IIOP (Internet Inter-ORB protocol) 112. The access requests are filtered through a security layer 108 which determines, typically based on a set of hardwired rules, whether to allow or disallow the requested access. The security layer may be a component of the protected resource (eg. the application server itself) or may operate as a separate entity (for example as part of a firewall system or device).
With current systems little or no attempt is made to analyze the nature of the access request, the type of client, or the type of protected resource. As such, security is often thought of as a simple “permit or deny” mechanism, designed in such a way as to understand the protected resources provided by the server, and to adhere to a predefined set of rules governing a user's or a client's access rights to those resources. There is little or no understanding of the manner in which the request is made, or the environmental setting in which a particular user may make a request to access a resource, and the security mechanism does not lend itself to easy modification of the rules to reflect new changes in business policy regarding security.
Attempts have been made to develop the concept of security and particularly server security to include information that reflects a user's particular environment, and the manner in which a request to access a particular secure resource is phrased. Similarly, attempts have been made to provide security mechanisms that can be easily modified to reflect changes in business policy, security policy, and access rights. These methods still typically require an application programmer to be responsible for assembling a set of business policy queries together and asking the question, “is this OK?—is this access acceptable according to the security rules?” What is needed is a mechanism to make this process all inclusive so that the programmer does not have to understand the business semantics and the business policy rules in order to be able to develop programs and applications that ask security related business policy questions.
Recently, a new set of requirements concerning the securing of resources has emerged from discussions with application server customers and system integrators. These new requirements are expressed in terms of security from the point of view of an application instead of infrastructure. A key differentiation within these new requirements is the existence of business policy enforcement. The enforcement of business policy is typically described in terms of actions that a user is “entitled” to perform based on the role in which they are acting and the context of the business request. Customers and system integrators are frustrated with the fact that they are required to embed code that enforces business policy within applications. Embedding this type of logic creates deployment problems, in that the application must be modified, tested, and re-deployed each time the business policies are changed. Given the rate at which business policy changes, the current requirements for modification and re-deployment are unacceptable.
Customers and system integrators would ideally like to have these new authorization capabilities universally applied across the different types of execution and resource containers, including for example those for Enterprise Java Bean (EJB), Web Applications (Servlet, JSP), as well as other types of business and resource containers. Role-based access control (RBAC) is becoming one of the primary form of authorization requested by customers and system integrators. The trend in use of roles allows organizational identity to be used as an abstract form of identity when making authorization decisions. The use of roles provides a mechanism to reduce both the cost and errors in the administration of application security since it simplifies the amount of administration.
The Java 2 Enterprise Edition (J2EE) defines a declarative form of role-based access control. However, because it is based on a declarative scheme, the association of roles to principals is static. In addition, the current Java 2 Enterprise Edition specification provides no means by which the context of a business request, such as the parameters of the request or the identity of the target, can be taken into account when determining the roles to be associated with a given principal. Consequently, application developers are required to implement business policy rules within the application to compute dynamic roles associations in order to support concepts like “owner.”
Customers and system integrators nowadays demand a richer set of authorization capabilities than those provided with the permission-based security defined by Java 2 security and the role-based access control defined in Java 2 Enterprise Edition. The foundation of the requirements for this richer level of authorization can be found in the intersection of classical authorization mechanisms, such as Access Control Lists, and business policy enforcement; and include the ability to take the context of the business request into consideration when making an authorization decision. The request context may include the identity of the target object, the value of the parameter of the request, and potentially environmental information such as the network or IP address of the initiating client.
The lack of a single mechanism through which to integration these new authorization capabilities, regardless of execution or resource container type, is a point of frustration with customers and system integrators. The Service Provider Interface (SPI) is the mechanism used by several application servers, including the WebLogic Server product from BEA Systems, Inc., San Jose, Calif., to allow integration with external authorization providers. This SPI realm has a number of limitations that limit it's ability to be used as a successful means to integrate 3rd-party authorization mechanisms, or new authorization capabilities being required by customers and system integrators.
One of the largest limitations with the current “realm” SPI is scope of enforcement. Currently, the enforcement scope of the realm mechanism does not cover resources such as Enterprise Java Bean and Web Applications. In particular, the realm is focused on RMI style resources such as JMS destinations, entries in JNDI, and servlets at a course-grained level. While the realm could conceivably be updated to hold the definition of the authorization policies required to support protection of such resources, it is the other limitations that ultimately make the realm an unrealistic mechanism to address all the authorization requirements.
The second limitation of the current realm SPI is point of enforcement. The current realm mechanism does not allow the point at which the decision is made to allow access to a protected resource to exist within the realm itself. Instead, the point of enforcement is within the application server itself. Because of this approach, the current realm is defined to support only a permission-based authorization mechanism where the realm simply acts as a database of Access Control Lists. The complexities of providing a Java 2 Policy object that can also support the Java 2 sandbox rules is unacceptable to most vendors.
Yet another limitation is the Enforcement Mechanism Support of the current realm SPI. As with the point of enforcement, the enforcement mechanisms allowed by the current realm SPI are limited to those based on permission-based authorization mechanisms. This is counter to the capabilities of the leading 3rd-party authorization providers, the integration of which is being requested by customers and systems integrators on a daily basis.
Together, these limitations constrain the types of authorization providers that can be integrated with an enterprise application server without minimizing the value proposition of the provider. There remains no current capability to obtain the context of the request in order to provide the rich authorization requested.
JAVA, JAVA TWO ENTERPRISE EDITION (J2EE), and ENTERPRISE JAVABEANS (EJB) are trademarks of Sun Microsystems, Inc. WEBLOGIC is a trademark of BEA Systems, Inc.